The present invention relates to a system and method for an improved computer automotive service equipment system.
Computerized automotive service and diagnostic equipment systems for measuring or testing various parameters and for providing maintenance or repair procedure instructions to an operator are generally known. Such systems utilize a central control processor residing within a data input computer, and various data input and storage means are connected to that computer, for example, vehicle mounted instruments sensors, manual data input keyboards and electronic database storage media.
Systems that utilize vehicle mounted sensors utilize those sensors to transmit raw signals representing measured quantities to a central control processor for comparison with stored specification data. From this comparison, the central processor computes a vehicle diagnostic state. In addition to providing input or measured data, such sensors also enable the central processor to conduct live real-time monitoring of the vehicle diagnostic state. Representative vehicle wheel alignment systems are disclosed in U.S. Pat. Nos. 4,383,370 and 5,208,646, whose teachings and disclosures are hereby incorporated by reference.
In operation, the measured data derived from the raw signals (or alternatively measured data derived from operator keyboard input) is compared to pre-stored specification parameters. Such specification parameters correspond to specific makes and models of vehicles or parts. A vehicle diagnostic state is obtained from the aforementioned comparison between measured and specification values, and the central processor provides an output perceptible by the operator on an output device. Such output devices usually comprise a CRT display, but many possibilities are evident, for instance sound or voice output or a paper hardcopy printout. From the information on the output device, an operator may thereby diagnose problems with the vehicle or part under inspection. In automotive service equipment in general, such as engine analyzers, brake testers, suspension testers, wheel balancers and the like, sensors are not necessarily vehicle mounted.
In addition to diagnostic procedures, existing systems allow operators to perform corrections once problems are detected from the vehicle diagnostic state output. Such systems can include step-by-step adjustment or repair procedure instructions to assist in such corrections. In such cases, the output functions to guide an operator or technician through a repair or adjustment procedure.
Various shortcomings exist among currently known systems of the type described above. For one thing, such computerized automotive service equipment usually comprises proprietary, closed computer systems. A manufacturer of such systems typically spends years developing software. The manufacturer has to customize the software to run on a single dedicated computer, and the resulting product has little or no flexibility to interchange and update different hardware and software elements. Each system runs different software, often on completely different operating systems designed for completely different hardware platforms. Each individual system also is incapable of being conveniently or easily updated. If a new development or improvement occurs, the manufacturer of the individual system typically has to issue an entirely new version release of the software and/or hardware in order to bring that improvement to market. The new release requires a complete rewrite. Not only do new versions often take years to complete. It is often so costly to release a new system that, as a practical matter, the manufacturer has to wait until enough improvements occur in order to justify the financial burdens of a new version release. This hampers the ability of the end user, the automotive service professional, to bring the latest technological improvements to the customer, the typical car driver.
In some instances, personal computers (PC""s) have been implemented in automotive service applications in an attempt to overcome the aforementioned problems. For instance, some vehicle wheel alignment systems have been implemented that use standard IBM-based PC""s in combination with the MICROSOFT WINDOWS 3.1 operating system. While such systems do represent a departure from the traditional monolithic closed systems of the past, a number of disadvantages remain. For instance, on a programming level, WINDOWS 3.1 does not support 32-bit addressing; it only supports 16-bit addressing using a 16-bit segmented addressing mode. This memory model is an idiosyncratic remnant of the old DOS 16-bit segmented addressing mode. Also, WINDOWS 3.1 uses only a primitive form of multitasking. WINDOWS 3.1 multitasking is process-based. That is, while multiple programs can run at the same time on the system, the operating system cannot run multiple parts of the same program at one time. One consequence of this is that it has previously been impossible to place videographic computer animation (for instance, an instructional video) on a display screen at the same time as the real-time live sensor readings are displayed. It has also not been possible to utilize particular sensor inputs as a prompt to initiate and execute portions of an automotive service application while the rest of the automotive service application continues to execute at the same time.
While in some fields it has been appreciated to overcome the limitations of a WINDOWS 3.1 based computer system with the implementation of newer 32-bit operating systems, such as WINDOWS 95, the same cannot be said of the automotive service equipment field. The WINDOWS 95 operating system utilizes 32-bit flat addressing. Furthermore, WINDOWS 95 utilizes not only process-based multitasking, but also thread based multitasking. Thread based multitasking allows several parts of the same program to run at the same time. All of the pertinent advances of WINDOWS 95 over the WINDOWS 3.1 operating system are being retained in the newer WINDOWS 98 operating system, and ought to remain through future versions as well. It would be advantageous to apply such features to the automotive service equipment field.
FIG. 1 is a stylized schematic showing a general overview of how an application interacts with the computer hardware in a WINDOWS 95 or WINDOWS NT operating system. Here, the kernal interface to the hardware is represented by a series of rings. Ring 0 is the hardware, or the core. For instance, this might include the CPU, video card, serial ports, et cetera. In Ring 1 resides the WINDOWS operating system kernal and virtual device drivers. Virtual device drivers are software objects that contain code which understands how to communicate with the underlying hardware. The WINDOWS kernal handles all calls and passing of information back and forth between the operating system and the various application programming interfaces (API""s). Ring 2 is where all WINDOWS application programming interfaces (API""s) reside and execute. Ring 3 is where all old DOS applications execute. In Ring 2 also resides self contained reusable software objects, called xe2x80x9cDLL""s.xe2x80x9d A DLL (xe2x80x9cDynamic Link Libraryxe2x80x9d) is a small computer program that may be shared by many different processes at the same time.
Other features of 32-bit operating systems such as WINDOWS 95 have heretofore been unappreciated in the automotive service equipment arts. WINDOWS 95 supports enhanced object oriented programming and object oriented design (xe2x80x9cOOP/OODxe2x80x9d). OOP involves the creation of software xe2x80x9cobjects.xe2x80x9d Software objects may be thought of as self-contained mini-programs within a program. Before OOP, programs primarily consisted of two basic elements, data and program instructions. Data elements are storage locations. Program instructions are commands the computer will follow to make decisions or manipulate data. A data element such as a variable, constant or structure had only one functionxe2x80x94to hold information. Instructions had only one functionxe2x80x94to perform some action. With the advent of software objects, the line between data and instructions becomes fuzzy. Objects are software entities that have properties. They can take action, like instructions, but also utilize data. One of the main virtues of software objects is their inherent reusability. Objects, being largely self-contained, may be purchased that perform many commonplace functions, such as database routines, mathematical algorithms, and input/output functions. Microsoft has now developed a WINDOWS NT version and a WINDOWS 98 version that can share hardware drivers across the different platforms. Many objects are included with the Microsoft Visual C/C++4.2 Developers Studio, an integrated software development environment for writing object oriented programs.
Object oriented applications are generally easier to create and modify than non-object oriented applications. If a portion of an application must be changed, all that is necessary is to change the particular software object in question. The modification will be transparent to the rest of the application. This is in contrast to prior systems in which an entire application had to be rewritten and debugged whenever a minor change was made to a single part of the application. Object oriented programs also do not have to reside completely on one computer. As long as the object can be accessed, the computer running the main application routine will be able to call the object and operate on it.
One consequence of the failure to utilize OOP in automotive service equipment applications is that it was heretofore impossible for an automotive service technician to create and customize his own sequential servicing routine on the shop floor. In other words, while in prior systems, a technician could select which servicing procedure to perform from a selection of menu options (random mode), he could not program a unique sequence of servicing routines that would make the computerized system take him through the same set of routines, step by step, each time (sequential mode).
In accordance with the object of the invention to overcome the disadvantages and limitations of the prior art as described above, the present invention provides a novel improved computerized automotive service equipment system.
In one embodiment, the computer causes the initiation of a servicing routine upon the detection of particular stimuli from the sensors. For instance, a runout correction procedure will be initiated upon the sensors detecting the initiation of the procedure at the vehicle wheel. In another embodiment, the novel system places instructional output on the output device simultaneously with an output representative of a vehicle diagnostic state. In yet a further embodiment, object oriented programming techniques are utilized to allow an automotive servicing application to be easily and conveniently updated. In a still further embodiment, an automotive service equipment system is provided in which the replacement of the sensor hardware only requires the replacement of a single software object or collection of objects instead of the rewriting of the entire application. In yet a further embodiment, a system is provided that enables the operator/technician to program the sequence in which the automotive service routine will proceed. Other features of the present inventions will be apparent to one of skill in the art from the detailed description below.